1. Field of the Invention
The present invention relates in general to the field of information processing, and more specifically to a system and method for providing security for variable domain resource data in an electronic data processing system.
2. Description of the Related Art
Data security issues often exist at the forefront of technology challenges faced by entities that maintain, use, view, manipulate, and otherwise access data. Often entities desire to grant different levels of access to different subsets of data to different principals. For example, in a product configuration context, it may be desirable to allow some principals to access one set of data and allow others principals to access another set of data, and the data represents a single, data configuration space.
Prior to discussing conventional data security solutions, for reference purposes, this application uses the following definitions unless otherwise indicated:
Resource Data (also referred to as a “resource”)                A resource data is data that can be viewed, manipulated, and otherwise accessed. Accessing the resource data can be controlled for security purposes. Examples of a resource data are: a file in a file system, a data element in an OLAP cube, and an attribute and/or rule for a specific combination of parts in a configuration model.        
Principal                A principal is a virtual or physical entity that has controlled access to a resource data, defined by the access control list (ACL). A principal can be a single entity or a group of entities. Examples of a principal are: the principal of a file system, the processes or principal querying for data in an OLAP cube, and the maintenance principal of a configuration model.        
Permission                A permission is the description of the type of access for which the principal is allowed, i.e. what the principal is allowed to do or not to do relative to the resource data. Examples of a permission are: the ability of a file system principal (principal) to delete a file (resource data) in a file system, the ability of the principal querying an OLAP cube to read a data element (resource data), and the ability of a maintenance principal (principal) to change an attribute for a combination of parts (resource data) in a configuration model        
Access Control List (ACL)                An ACL is an example of a control structure that provides secure access to resource data. The ACL defines what permission a principal has to a specific resource data or resource data. Examples of an ACL are: the statement that specifies that a specific principal (principal) can delete (permission) a specific file (resource data) in the file system, the statement that specifies that a specific principal in an OLAP query can read (permission) a specific data element (resource data), and the statement that specifies that a specific maintenance principal (principal) can change (permission) the attribute for a specific combination of parts (resource data).        
Condition                A condition is a function that takes the properties of a resource data as inputs and returns a Boolean output (Yes/No). A condition can facilitate the definition of which resource data an ACL may apply.        
Part                A part represents a single component from a larger, more complex system. Parts are combined in different ways to define different instances of the more complex system. For example, “V6 engine” or the exterior color “red” can be parts on a vehicle, and a specific hard disk drive can be a part on a computer.        
Part Group                A part group, also called a group, represents a collection of related parts. For example, the “Engines” group might contain the parts “V6 engine” and “4 cylinder engine.”        
Attribute                An attribute represents a particular detail about a part or part group. Attributes describe details about the part or part group. A single part or part group can have many attributes. For example, the part “V6 engine” might have a price attribute of “$500,” a weight attribute of “1,000 lbs” and a description attribute of “six cylinder gas engine.” Also, an attribute for a given part or part group may change depending on context, meaning what other parts are present. For example, the price attribute for the “V6 engine” might be “$500” when the “XLT trim” part is present and “$800” when the “XL trim” part is present.        
Configuration Model                A configuration model defines the compatibility relationships between the parts that comprise a specific type of system. It can be used to determine, for example, which parts are compatible with which other parts, and provide additional details about specific relationships. For example, a vehicle configuration model can indicate that “red” (a part) is the standard color feature for a specific vehicle, but that the color red is not compatible with “V6 engine” (a part). A configuration model also contains additional information needed to support specific queries about that system.        
Conventional data security solutions fall into one of the following two categories:                1) Solutions where each resource data has its own ACL or series of ACLs that control access to it.        2) Solutions where there are many ACLs that control access to many resource data.        
Solutions for applications with very simple security needs will usually fall into the first category. These applications are characterized by relatively few resource data, and these resource data may not have well defined properties. Each resource data has its own ACL that controls access to the resource data. The security solutions for these applications become slower and more difficult to manage when the number of resource data increases.
A large number of applications require a much more complex security solution. Applications in the second category can be characterized by a large or very large number of resource data that have well defined properties or domains. There are typically many ACL-to-resource data relationships. An example of a 1 ACL-to-many resource data relationship is an ACL that controls access to all row and columns in a database table. Another example is an ACL associated with a directory in a file system that also controls access to all files in that directory. An example of a many ACL-to-1 resource data relationship is a multi-level hierarchy of directories in a file system where a separate ACL exists for each directory in the hierarchy along with rules of inheritance that define how the many ACLs combine together to control access to a file.
As the number and complexity of the conditions and resource data increases, the conventional data security solutions become increasingly difficult to maintain, performance decreases, and the possibility of ill defined or overlapping conditions in ACLs increases, thereby necessitating a definition for conflict resolution process.
An application that points out the shortcoming of the two conventional data security solutions is product configuration. A resource data in a product configuration model is an attribute and/or rule for a part that that applies to a valid or invalid permutation of parts from one or more part groups (properties of the attribute or rule). The number of possible resource data in a configuration model can easily reach beyond 10^10 (10 part families with 10 parts in each family).
Existing security solutions for product configuration typically fall into one of the two categories discussed above.
FIGS. 1A and 1B depict a data security solution 100 for a configuration model that divides a configuration model into many smaller, separate configuration models. The desired data access control business logic 102 for security solution 100 represents an example desired access control for principals 1 and 2 to the data (particularly the resource data) in configuration model 104. The data access control business logic 102 is “Principle 1 may edit rules and attributes of part F1 that mention B1” and “Principle 2 may edit rules and attributes of part F1 that mention A2 and B2.” To achieve the desired security business logic 102, the comprehensive configuration model 104 is divided into many smaller, separate configuration models, 106, 108, and 110. Each of the configuration models 104, 106, 108, and 110 contain a Part, a Rule or Attribute, and a Part or Part Combination (also referred to as “Properties”). The part families represented are A, B, and F, and the parts in each part family are {A1, A2}, {B1, B2}, and {F1, F2}. The Rule or Attribute describes a logical relationship between a first part and another part or part combination. For example, the first part F1 is compatible with the combination of parts A1 and B1. Part F1 is incompatible with the combination of parts A1 and B2. Part F1 is compatible with part A2. Each of the smaller, sub-configuration models 106, 108, and 110 is then treated as a resource data. A principal is assigned permissions to each of the sub-configuration models 106, 108, and 110 by an ACL 112.
There are many problems with data security solution 100 in the context of a configuration application. The sub-configuration models 106, 108, and 110 need to be combined together before they can be processed by a configuration engine, which is a difficult task to perform manually and algorithmically. It is more difficult to manage and maintain separate sub-configuration models than one larger model. And finally, as the domain of the configuration model increases, the number of sub-configuration models will need to increase, making the task of managing the ACL 112 more difficult.
FIG. 2 depict a data security solution 200 that adds “helper” part families to control access to various portions of data. To achieve the desired security business logic 102, the comprehensive configuration model 104 is modified to add additional “helper” part families “S1” and “S2”, as depicted in configuration model 202, to use as categories to associate with a set of resource data. These “helper” part families S1 and S2 do nothing but make it possible to categorize the resource data for use with conditions in the ACL 204. The ability to use conditions allows the ACL to define security for more than one configuration resource data at a time. Solution 200 is better than solution 100 because it does not require the configuration model 104 to be divided up into sub-configuration models. It is more scalable that solution 100 because multiple resource data can be secured with a fewer number of ACLs.
However, solution 200 has three major drawbacks. First, adding “helper” part families increases the complexity of the configuration model 104 by modifying the resource data in order to create security categories. This extra complexity increases storage and processing memory requirements and reduces processing performance. Second, mapping the helper parts so that the correct resource data can be addressed in the ACL 204 is difficult to set up and maintain. The right combination of helper parts must be associated with correct resource data. Third, it is possible to define conflicting ACLs.
Product configuration environments present many data security challenges. FIGS. 3 and 4 depict basic concepts of product configuration and the data involved with product configuration. Computer assisted product configuration continues to offer substantial benefits to a wide range of users and industries. FIG. 3 depicts a conventional product configuration process 300 performed by a configuration engine 303. The configuration process 300 represents one embodiment of an inference procedure. In one embodiment of a conventional inference procedure, configuration query 302 is formulated based on user configuration input, a configuration engine performs the configuration query 302 using a configuration model 304, and the configuration engine provides an answer 306 to the configuration query 302 based on the configuration query 302 and the contents of the configuration model 304. The answer 306 represents a particular response to the configuration query 302.
A configuration model 304 uses, for example, data, rules, and/or constraints (collectively referred to as “data”) to define compatibility relationships between parts (also commonly referred to as “features”) contained in a specific type of product. A product configuration is a set of parts that define a product. For example, a vehicle configuration containing the parts “V6 engine” and “red” represents a physical vehicle that has a red exterior and a V6 engine. A product can be a physical product such as a vehicle, computer, or any other product that consists of a number of configurable features such as an insurance product. Additionally, a product can also represent a service such as financial services, insurance services, or consulting services.
A configuration query (also referred to as a “query”) is essentially a question that is asked about the parts, relationships, and attributes in a configuration model. The answer returned from a configuration query will depend on the data in the configuration model, the approach used for answering the question, and the specifics of the question itself. For example, one possible configuration query, translated to an English sentence, is the following: For the given configuration model, are the parts “red” and “V6 engine” compatible with each other? Another possible configuration query is the following: For the given configuration model, is the “V6 engine” part standard or optional when in the presence of the “XLT trim”, “XL trim”, “USA”, and “Canada” parts, wherein “standard” and “optional” are attributes?
The configuration model 304 can be used to determine, for example, which parts are compatible with other parts, and provide additional details around specific relationships. For example, a vehicle configuration model can indicate that “red” (a part) is the standard feature from the color part group for a specific vehicle and “red” is not compatible with “V6 engine” (a part). Configuration model 304 may also contain additional information needed to support specific product related queries. Configuration models can be developed in any number of ways. U.S. Pat. No. 5,825,651 entitled “Method and Apparatus for Maintaining and Configuring Systems”, inventors Gupta et al., and assigned to Trilogy Development Group, Inc., describes an example configuration engine and rules based configuration model. U.S. Pat. No. 5,825,651 (referred to herein as the “Gupta patent”) is incorporated herein by reference in its entirety. U.S. Pat. No. 5,515,524 entitled “Method and Apparatus for Configuring Systems”, inventors John Lynch and David Franke, and assigned to Trilogy Development Group, Inc., describes another example configuration engine and constraint based configuration model. U.S. Pat. No. 5,515,524 (referred to herein as the “Lynch patent”) is also incorporated by reference in it entirety.
FIG. 4 depicts an example configuration model 400 of a product represented in a graphical, tree based form. The product can be configured to include part combinations A1, B1 or B2, C1, X1 or X2, and Y1 or configured to include part combinations A2, B2, C2, X2, and Y1 or Y2. The configuration model 400 includes rules to define these part relationships. Table 1 represents an example rule set, wherein “S” represents “standard” and “O” represents optional. Configuration model 400 represents a relatively non-complex configuration model. Actual configuration models for a single product can include hundreds of thousands or more parts, rules, and attributes.
TABLE 1Example Configuration Rules for a ProductA1 S ALLA2 O ALLB1 S A1B2 S A2B2 O A1C1 S A1C2 S A2X1 S C1X2 S C2X2 O C1Y1 S C1Y1 S C2Y2 O C2